home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940335.txt < prev    next >
Internet Message Format  |  1994-11-13  |  18KB

  1. Date: Mon, 10 Oct 94 04:30:19 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: List
  6. Subject: Ham-Digital Digest V94 #335
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Mon, 10 Oct 94       Volume 94 : Issue  335
  11.  
  12. Today's Topics:
  13.               continuous data transfer over +/- 2 miles
  14.                     FAX Software for KAM/KAM Plus?
  15.                  WANT: Computer Aided Dispatch system
  16.  
  17. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  18. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  19. Problems you can't solve otherwise to brian@ucsd.edu.
  20.  
  21. Archives of past issues of the Ham-Digital Digest are available 
  22. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  23.  
  24. We trust that readers are intelligent enough to realize that all text
  25. herein consists of personal comments and does not represent the official
  26. policies or positions of any party.  Your mileage may vary.  So there.
  27. ----------------------------------------------------------------------
  28.  
  29. Date: Sat, 8 Oct 1994 14:05:56 GMT
  30. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  31. Subject: continuous data transfer over +/- 2 miles
  32.  
  33. In article <stephenh.34.002C746A@autonomous.com> stephenh@autonomous.com (Steve Hochschild) writes:
  34. >I need to send a continuous data stream at about 1200 baud over a distance of 
  35. >about 2 miles. 
  36. >
  37. >I am trying to instrument an amateur race car and send real time telemetry 
  38. >back to the pits.  I am a total novice on this, but someone told me packet 
  39. >radio would be a way to go.  After reading the FAQ, I don't think that this is 
  40. >so, rather, I think I need some other form of digital transmission...
  41. >Any ideas ???
  42.  
  43. Packet may not be best for pure telemetry. It will give you an error
  44. free data stream by error detection and retries, but you'd have to run
  45. at least 9600 baud packet to get 1200 bps raw throughput, and really 
  46. need a transceiver on each end. If instead you can tolerate the occasional 
  47. transmission error, or use FEC, then what you want is a simple half-duplex 
  48. modem over radio. The most ancient of these, the Bell 202 Standard type, 
  49. will give you a raw 1200 bps throughput. A PSK modem would be more robust, 
  50. however. The ones used to decode amateur satellite telemetry would do.
  51.  
  52. Telco modems generally can't be used because of their internal "smarts"
  53. which insist on attempting to setup a duplex link, and dropping it if
  54. carrier is momentarily lost. Only the ancient dumb modems meant for
  55. leased lines can generally be used.
  56.  
  57. Gary
  58. -- 
  59. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  60. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  61. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  62. Lawrenceville, GA 30244     |                     | 
  63.  
  64. ------------------------------
  65.  
  66. Date: Sun, 9 Oct 94 14:33:30 -0500
  67. From: Kevin Charles Alewine <kcalewine@delphi.com>
  68. Subject: FAX Software for KAM/KAM Plus?
  69.  
  70. Anyone had any luck finding a good FAX send/receive program for
  71. the KAM? Freeware, shareware, or commercial, any suggestions
  72. would be appreciated!
  73.  
  74. Thanks!
  75. --
  76. -------------------------------------------------
  77. |  K.C. Alewine, South Lake Tahoe, California   | Air Traffic Controller
  78. |  Internet: kcalewine@delphi.com               | Lake Tahoe ATCT
  79. |  Ham packet radio: WI7C@WA6EWV.#NOCAL.CA.USA  | Ham Call WI7C
  80. -------------------------------------------------
  81.  
  82. ------------------------------
  83.  
  84. Date: Sun, 09 Oct 94 09:50:32 EDT
  85. From: pp000814@interramp.com
  86. Subject: WANT: Computer Aided Dispatch system
  87.  
  88. I would like to know what info turns up here. Several people who work for me 
  89. will be attending a meeting at the Dulles Marriott this week to discuss 911 
  90. service for PCS and Celluar users.
  91.  
  92.  
  93.  
  94.  In article <CxBn4C.7yB@peacock.tcinc.com>, <sjames@tcinc.com> writes:
  95. > Newsgroups: rec.radio.amateur.digital.misc
  96. > Path: 
  97. interramp.com!psinntp!rutgers!netnews.upenn.edu!msuinfo!caen!spool.mu.edu!sol.c
  98. tr.columbia.edu!news.msfc.nasa.gov!news.larc.nasa.gov!lerc.nasa.gov!purdue!yuma
  99. !csn!nowhere!aitsun20!sjames
  100. > From: sjames@tcinc.com (Scott James)
  101. > Subject: WANT: Computer Aided Dispatch system
  102. > Message-ID: <CxBn4C.7yB@peacock.tcinc.com>
  103. > Sender: news@peacock.tcinc.com (Internet News Administration)
  104. > Nntp-Posting-Host: aitsun20
  105. > Organization: TeleCommunications, Inc.
  106. > X-Newsreader: TIN [version 1.2 PL2]
  107. > Date: Fri, 7 Oct 1994 21:16:59 GMT
  108. > Lines: 14
  109. > I'm looking for a Computer Aided Dispatch (CAD) system
  110. > that links radio modem technology with a GIS display.
  111. > These systems are used by Federal Express (I think)
  112. > and 911 agencies.
  113. > If you know of any products or companies that can help
  114. > me find such a system, please email me with the info.
  115. > thanks in advance!
  116. > scott james
  117. > N0LHX
  118.  
  119. ------------------------------
  120.  
  121. Date: Sat, 8 Oct 1994 13:23:18 GMT
  122. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  123.  
  124. References<9410040039.AA02497@enterprise.chinalake.navy.mil> <1994Oct4.141109.27381@ke4zv.atl.ga.us>, <374q1p$n6h@u.cc.utah.edu>
  125. Reply-To: gary@ke4zv.atl.ga.us (Gary Coffman)
  126. Subject: Re: 56k+ Packet System
  127.  
  128. In article <374q1p$n6h@u.cc.utah.edu> val@cs.weber.edu (Val Kartchner) writes:
  129. >In article <1994Oct4.141109.27381@ke4zv.atl.ga.us>,
  130. >Gary Coffman <gary@ke4zv.atl.ga.us> wrote:
  131. >>Well then you need a GRAPES 56kb RF modem. It's $250, and with the
  132. >>necessary transverter and digital interface, it's still under $600.
  133. >>Most of the voice radios being used for 1200 baud packet cost nearly
  134. >>that much. 46 times the throughput for about the same money is an
  135. >>unbeatable deal.
  136. >
  137. >But what specific components do you need and where do you get them?  I've
  138. >got a catalog from Down East Microwave, and I don't know what transverter
  139. >to put with the GRAPES modem.  I need enough power output to reliably get
  140. >the signal to go 8 miles.
  141.  
  142. Their no tune 432 transverter may be sufficient by itself for such 
  143. a path, assuming LOS and directional antennas. Or you can add the 
  144. amplifier they offer. They offer the whole package assembled and
  145. tested, or as separate kits. We typically operate 3-7 watt systems 
  146. over 50-100 mile paths. Those paths are mountaintop to mountaintop,
  147. but using omni vertical antennas on at least one end of the path.
  148. For non-LOS use, more power, or a gain antenna, may be required.
  149. We have one user who's running 100mW and a 1/4-wave vertical, but 
  150. he can see the switch on the mountain about 10 miles away.
  151.  
  152. You need about 2 microvolts into the modem to get a low BER, less
  153. than one error in a million bits. So you can do any necessary path 
  154. calculations based on that.
  155.  
  156. Gary
  157. -- 
  158. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  159. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  160. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  161. Lawrenceville, GA 30244     |                     | 
  162.  
  163. ------------------------------
  164.  
  165. Date: Sat, 8 Oct 1994 13:49:31 GMT
  166. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  167.  
  168. References<9410040039.AA02497@enterprise.chinalake.navy.mil> <36sg1g$11l8@hermes.acs.ryerson.ca>, <36uta3$50k@sbrick.cs.sunysb.edu>
  169. Reply-To: gary@ke4zv.atl.ga.us (Gary Coffman)
  170. Subject: Re: 56k+ Packet System
  171.  
  172. In article <36uta3$50k@sbrick.cs.sunysb.edu> rick@cs.sunysb.edu (Rick Spanbauer) writes:
  173. >Donald Jeff Dionne (jeff@riddler.ee.ryerson.ca) wrote:
  174. >: Erich Muschinske (erich@enterprise.CHinalake.navy.MIL) wrote:
  175. >: : >Sorry to rain on your parade, but others have been down the path 
  176. >: : >you want to take before you, and it doesn't work. Adapting high
  177. >: : >speed telephone modem techniques to multipoint to multipoint radio 
  178. >: : >systems is a lost cause. The problems of packet radio are *different* 
  179. >: : >from those of the telephone network, and require different solutions.
  180. >: Not really.  Multipath and such are impediments to any modulation scheme that
  181. >: relies on phase information, such as QAM but it can still be workable.
  182. >
  183. >    I wouldn't be too quick to dismiss QAM out of hand.  The HDTV and
  184. >    catv folks are looking hard at VSB, QAM for both wired and broadcast
  185. >    systems.  These system rely on adaptive equalizers to deal with
  186. >    reflections, though we'll need a fairly long one in over the air apps..
  187. >    Any of these systems promise >> 10 mbps.  To the best of my knowledge,
  188. >    both are still untested in broadcast applications, however.
  189.  
  190. QAM is fine, but not over typical voice grade amateur radios. The
  191. GRAPES RF modem uses MSK, but it would generate QAM by a relatively
  192. simple EPROM change. The detector would have to be redesigned however.
  193. That's certainly doable, and may be an upgrade path for the modem. What 
  194. the RF modem offers that voice grade radios don't offer, however, is a 
  195. consistent RF section with known phase, frequency, and amplitude responses. 
  196. You'll never get that from a random collection of amateur voice grade radios, 
  197. and DSP can't compensate for *all* of them on the same channel at the same 
  198. time. There's no way to *train* to multiple signals from multiple *different*
  199. kinds of radios coming along multiple paths in a random packet by packet 
  200. sequence.
  201.  
  202. >: I think what needs to happen is for us to adopt a standard for high speed 
  203. >: packet over standard bandwidth channels.  With *very* little effort, 19.2 is
  204. >: more than possible, and probabily 38.4 without too much trouble at all.  Of
  205. >: course multipath and fading will kill it :-) who cares?  for local stuff,
  206. >: I'll live with that, and the high speed backbone links can stay ugly low
  207. >: tech FSK (that went out with the 1970, IMHO).
  208. >
  209. >    At this point in time, we should aim much, much higher than 
  210. >    19200.  I've read at least a couple of papers over the past year
  211. >    describing 80-128 kbps modems implemented in fairly slow DSP.  IMO,
  212. >    any interesting, modern application, say talking head teleconferencing,
  213. >    wants 100 kbit/sec or more BW delivered to the user.  We should be
  214. >    aiming for a few mbit/sec per channel, and at least 256 kbit/sec
  215. >    delivered to the user.  
  216.  
  217. We have 128 kb *now* with modified GRAPES RF modems, and 256 kb is within
  218. conception without major modifications. Switching to multi-level QAM 
  219. could double or triple even that, though paths would require higher SNR
  220. to give acceptable BER. Of course these are all *raw* rates, use of
  221. compression will allow even higher effective throughputs with any of these
  222. systems. To go above 1 Mbit/s raw will require rather fundamental redesign
  223. of equipment. But crude FSK equipment with that throughput is now available
  224. in the microwave range.
  225.  
  226. >: Another thing we need to realize is that $600 is just plain silly, and far
  227. >: out ot reach of the end user.  It's got to be $150 and use you hand held.
  228.  
  229. This is the fundamental fallacy of amateur packet. Anyone seriously doing
  230. packet will dedicate a radio to that use. Take the typical FT-530 at around
  231. $500 and the typical 9600 TNC such as the Kantronics 9612 at $220, and
  232. you've *already* spent more than needed for a 56 kb system, and your system
  233. is much less capable and reliable than the 56 kb unit.
  234.  
  235. >: All very do-able, but there are lots of issues to consider for the hardware.
  236.  
  237. It's *not* doable at amateur volumes. The market is too small to allow
  238. hitting a $150 price point with a DSP modem. And even if you could retail
  239. it for $300, you still have all the limitations of varying models of voice
  240. radios I've outlined in other messages.
  241.  
  242. >    Perhaps the most important aspect of developing new modems is to have
  243. >    the stuff available off the shelf.  In these days of surface mounted
  244. >    components, it is simply impractical to have people stuff a board
  245. >    with fine pitch 208 pin PQFP's using their Radio Shack 40 watt iron....
  246.  
  247. That's right, they have to spend $50 for a static hot air torch like
  248. the Weller Pyropen. Works fine for SMD assembly. SMD is definitely the
  249. wave of the future for all homebrew construction. Amateurs are going
  250. to have to get used to it. (The existing GRAPES modem doesn't use SMD
  251. however, though future versions might.)
  252.  
  253. Gary
  254.  
  255. -- 
  256. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  257. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  258. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  259. Lawrenceville, GA 30244     |                     | 
  260.  
  261. ------------------------------
  262.  
  263. Date: Sat, 8 Oct 1994 13:11:16 GMT
  264. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  265.  
  266. References<9410040039.AA02497@enterprise.chinalake.navy.mil> <36u4fd$56h@push.stack.serpukhov.su>, <Cx9FrL.IxF@world.std.com>
  267. Reply-To: gary@ke4zv.atl.ga.us (Gary Coffman)
  268. Subject: Re: 56k+ Packet System
  269.  
  270. In article <Cx9FrL.IxF@world.std.com> dts@world.std.com (Daniel T Senie) writes:
  271. >In article <36u4fd$56h@push.stack.serpukhov.su>,
  272. >Victor Voronkov <victor@stack.serpukhov.su> wrote:
  273. >>Erich Muschinske (erich@enterprise.CHinalake.navy.MIL) wrote:
  274. >>> Don't be too fast to dismiss this idea.  One of the things packet networking
  275. >>> desperately needs is a cheap high speed data link.  This is necessary for
  276. >>> operating a cellular packet concept.  It would only have to work with the
  277. >>> radio on the other end, so adapting would not be out of the question.  If
  278. >>> the price of a link could come down to about $600, I would be very interested.
  279. >>IMHO any attempt to get speed more than 9600 on HandHeld or other 'voice'
  280. >>Radio is problem. Even if we find new modulation. With half-duplex
  281. >
  282. >Can I ask a question here? How is it possible to get the necessary S/N ratio
  283. >and other such to get a V.32bis modem to operate correctly over a Cell Phone?
  284. >It seems to me that it IS possible for cell phones to provide a clean enough
  285. >signal to do data over them, so why do hams have so much trouble getting
  286. >the needed S/N ratio to run at 9600? I must really be dense and missing
  287. >something. I understand that the example of V.32bis (14.4kbps) over cellphone
  288. >is point-to-point. So are most amateur 56K links. Why can't we do a high
  289. >speed link over inexpensive gear and limited bandwidth? It seems to work
  290. >for cell...
  291.  
  292. You *are* missing something Dan. It's not SNR that's the problem. While
  293. it's true that most ham HTs are sorely lacking in adequate SNR over many
  294. paths for *any* type of modulation, including voice, hence the term handi-
  295. scratchie, that's *not* the main problem. Cellular phones are like the
  296. rest of the telephone system in that the phone network handles the addressing
  297. and routing *out of band*. This means that when the phone rings, the modem
  298. *knows* the signal is for it, and can initiate a *training* sequence with
  299. the modem on the other end to equalize and utilize the one transmission 
  300. path then in use. It is an *exclusive* circuit with no other modem signals
  301. present. 
  302.  
  303. The only difference that a cellular modem faces versus wireline modems
  304. is occasional signal dropouts due to handoffs, and the usual multipath 
  305. concerns. Therefore special modem parameters have to be used such as slow 
  306. disconnect so that the modem won't drop the connection during a brief handoff 
  307. outage, and robust error detection to handle the multipath induced symbol 
  308. errors.  We already have all that in packet.
  309.  
  310. What we *don't* have on packet is out of band routing and addressing,
  311. and what we *don't* have on packet is *exclusive* use of a frequency
  312. for a pair of stations. A packet modem has to successfully decode the
  313. header of *every* packet on the channel to assure that the packet either
  314. is or is not addressed to it. It *cannot* initiate a training sequence
  315. every time it hears a packet it can't decode. *That's* why packet modems
  316. can't use training, and training is the key to high speed data over a
  317. voice grade circuit. Every telco modem over 2400 baud uses some form
  318. of training at call setup. In packet, setup must be on a packet by
  319. packet basis, and that won't work because not all packets on the
  320. channel are addressed to the same modem.
  321.  
  322. With the typical Kenmore, Yahoo, Icky, and Motrash radios used by
  323. amateurs, no two of them will have the same bandpass characteristics.
  324. Training is *essential* to compensate for that, and for off channel
  325. stations. Amateur equipment doesn't have the frequency stability of
  326. commercial equipment, so it isn't unusual to have one or more radios
  327. a kilohertz or more off channel. Nor is it unusual to see wide differences
  328. in deviation from one radio to the next, even among those of the same
  329. make and model. Any modulation used has to be tolerant of all those
  330. errors *without* compensation on a packet by packet basis. That's why
  331. systems as slow as 9600 baud are difficult to setup with more than 
  332. two stations. 2400 baud is about as fast as an uncompensated system
  333. can work with multiple players. 
  334.  
  335. The limitation is *not* with the modems, it's with the *radios*.
  336. To successfully use high speed packet, we *must* have radios with
  337. identical response characteristics, and that means dedicated data
  338. radios, all optimized for the *same* response. Now it may be possible
  339. to compensate *all* radios the same way in a system by use of DSP,
  340. but it's not likely. There are two many variables outside the control
  341. of the DSP, such as whether the radio is on channel center or not,
  342. and the differing multipath from one radio path to the next. We
  343. need identical radios, *and* a modulation that is tolerant of certain
  344. types of errors. Such systems exist, I keep pointing to the GRAPES
  345. 56kb RF modem as an example, but insistance on using voice grade
  346. amateur equipment for high speed packet is futile. Amateur packet 
  347. networks are *not* like the telco network, and telco techniques 
  348. won't work.
  349.  
  350. Gary
  351. -- 
  352. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  353. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  354. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  355. Lawrenceville, GA 30244     |                     | 
  356.  
  357. ------------------------------
  358.  
  359. End of Ham-Digital Digest V94 #335
  360. ******************************
  361.